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MANAGING AND EXTENDING ATTRIBUTE VALUES 
FOR PUBLIC KEY CRYPTOGRAPHY STANDARDS 

BACKGROUND OF THE INVENTION 

1. Technical Field 

The present invention relates generally to an 
improved data processing system and in particular to a 
method and an apparatus for implementing Public Key 
Cryptography Standards (PKCS) . Still more particularly, 
the present invention provides a method for manipulating 
PKCS-attributes and user-defined attributes in a PKCS 
compliant system. 

2. Description of the Related Art 

Public Key Cryptography Standard (PKCS) is a set of 
documents published by RSA Laboratories and serves to 
define data types and algorithms used in public-key 
cryptography. Public-key cryptography is a technology in 
which encryption and decryption involve the use of a 
public key and a private key, and either can encrypt 
and/or decrypt data. A user gives his or her public key 
to other users, keeping the private key to himself or 
herself. Data encrypted with a public key can be 
decrypted only with the corresponding private key, and 
vice versa. 

The PKCS set of standards has been developed to 
assure that software using cryptography at two different 
sites could work together even when the software is 
developed by different vendors for a variety of purposes. 
In particular, standards are being developed to allow 
agreement' on digital signatures, digital enveloping, 
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digital certification, and key agreement. However, 
interoperability requires strict adherence to 
communicable formats, and PRCS provides a basis for 
interoperable standards in heterogeneous environments. 
5 The present set of PRCS standards includes: 







PKCS 


#1: 


RSA Encryption Standard; 






PKCS 


#3: 


Dif f ie-Hellman Key Agreement Standard; 






PKCS 


#5: 


Password-Based Encryption Standard; 






PKCS 


#6: 


Extended-Certificate Syntax Standard; 
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PKCS 


#7: 


Cryptographic Message Syntax Standard; 






PKCS 


#8: 


Private-Key Information Syntax Standard; 






PKCS 


#9: 


Selected Attribute Types; 
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#10 


: Certification Request Syntax Standard; 


J 
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#11 


: Cryptographic Token Interface Standard; 
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PKCS 


#12 


: Personal Information Exchange Syntax 






Standard; 






Cl 




PKCS 


#13 


: Elliptic Curve Cryptography Standard; and 






PKCS 


#15 


: Cryptographic Token Information Format 






Standard. 







20 Two independent levels of abstraction have been 

provided by these standards. The first level is message 
syntax, and the second level is specific encryption 
algorithms. The intention has been that message syntax 
and specific algorithms should be orthogonal. In other 

25 words, a standard for the syntax of digitally signed 
messages should be able to work with any public -key 
algorithm, not just RSA, the public-key algorithm 
invented by Rivest, Shamir, and Adleman involving 
exponentiation modulo the product of two large prime 

30 numbers; and a standard for RSA should be applicable to 
many different message syntax standards. 
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PKCS provides definitions of data objects that may- 
be created, sent, and received between parties to a 
communication, while other standards are used to define 
the encoding syntax of the data streams containing these 
5 types of data objects. Abstract Syntax Notation One, 
abbreviated ASN.l, is a notation for describing abstract 
types and values. The Basic Encoding Rules (BER) for 
ASN.l give one or more ways to represent any ASN.l value 
as an octet string. The Distinguished Encoding Rules 

10 (DER) for ASN.l are a subset of BER, and give exactly one 
way to represent any ASN.l value as an octet string. DER 
is intended for applications in which a unique octet 
string encoding is needed, as is the case when a digital 
signature is computed on an ASN.l value. ASN.l and DER 

15 encoding are general purpose methods that can be applied 
to many domains in addition to PKCS. 

On,e _pf the PK CS standard documents, PKCS #9, defines 
a set of attribujtes_that_^*^^ used in other PKCS 
standards, PKCS #9 defines selected attribute types for 

20 use with various types of other data objects within otheir 
PKCsIIs-tandarids , such as PKCS #5 extended certificates and 
PKCS #7 cryptographic messages. For example, PKCS #7 
defines the syntax for several cryptographically 
protected messages, including encrypted messages and 

25 messages with digital signatures. PKCS #7 also allows 
arbitrary attributes, such as signing time, to be 
authenticated along with the content of a message. 
Originally an outgrowth of Internet Privacy-Enhanced 
Mail, PKCS #7 has become the basis for the widely 

30 implemented Secure/Multipurpose Internet Mail Extensions 
(S/MIME) secure electronic mail specification, an 
Internet e-mail security standard that employs public key 
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encryption. PKCS #7 has become a basis for message 
security in systems as diverse as the Secure Electronic 
Transaction (SET) specification for bank systems. 

Since PKCS #9 provides attributes to support other 
5 components in the PKCS set of standards, it is important 
that any software that processes PKCS #9 attributes 
handle these attributes in a robust manner. For example, 
a software application could be written such that it has 
knowledge of attributes defined as part of the PKCS #9 

10 standard, and the application could treat unknown 

attributes as "undefined" attributes. However, given the 
fact that this set of standards co ntinues to ,. evolve ,^_it 
is i mp o r t an t for sof tw_are „ thafc^hand-l e s-^EKC S_,^J9_a ttributes 
ca n handle ''extended^ _aJ:.trdbu-te-^Qr^user^de f ined . 

15 ^a^tribu-tes.. Beyond the attributes that are defined as 
part of the standard, a software developer may desire to 
process a user-defined set of attributes along with the 
standard list of attributes. 

Therefore, it would be advantageous to have an 

20 architecture and a method for manipulating PKCS 

attributes that allows a data processing system to be 
extended to accommodate additional attributes. 
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SUMMARY OF THE INVENTION 



A method and system for. processing PKCSrattributes 
and user-defined attributesy^is provided. Attributes are 
5 registered with a PKCS9 gateway class, and the attributes 
include user-defined attributes and PKCS-standard defined 
attributes. Each of the registered attributes is 
associa tively stored with a n identifier. An 
object-oriented method in the PKCS9 gateway class may be 
10 called with a parameter containing an object identifier 
for an attribute. An a ttribute mapping da ta structu re is 
searc,hed^usj jig the obj ect id entifie r in the received 
par:ameJten,,_arid_in^res^on^e^ a matching o bj ect 

identifier-,-— a- elass^-identj^fi^^ has been 



15 associa±J^vely_storej^ with_the matching object identifier 
i s r e^tx ie ved^f rom ^t^he-a-t-tr i-bU'te-mappi-nc?^ data s t r uctur e . 
A method in the class identified by the class identifier 
is then called. The called method may include an 



ope ration f ori^cAnst ruction, attribute conversion to and 
20 from DER-encoding, attribute differentiation, and 
a'ttribute value extraction. A class hierarchy of 
attribute types is base d on a n a bstract class f or all 
attribute objects with a subclass for undefined 
attributes and a subclass for defined at tribute s. The 
25 subclass for defined attributes is further decomposed 
into a subclass for each PKCS-defined attribute and a 
subclass for each user-defined attribute. 



Docket No. AUS990800US1 



. BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 
5 invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 
10 Figure 1 is a exemplary representation of a 

distributed data processing system in which the present 
invention may be implemented; 

Figure 2 is an exemplary block diagram of a data 
processing system that may be implemented as a server; 
15 Figure 3 is a diagram showing the Abstract Syntax 

Notation for the X.500 Attribute type; 

Figure 4 is a diagram showing two examples of PKCS 
#9 attributes, each with sample values; 

Figure 5 shows an example of DER-encoding in 
2 0 hexadecimal format of the two PKCS #9 objects shown in 
Figure 4 ; 

Figure 6 is a class hierarchy diagram that shows an 
exemplary set of classes for use in the software 
methodology of the present invention for implementing 
2 5 PKCS-at tribute-related operations in an extensible 
manner ; 

Figure 7A is a flowchart outlining an exemplary 
operation for requesting an attribute object via the 
PKCS9 class in accordance with an embodiment of the 
30 present invention; 
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Figure 7B is a diagram showing an example format of 
a user-defined attribute configuration file that maps 
attribute object identifiers to the classes that 
implement the attributes; 
5 Figure 7C is a table showing an example of mappings 

from object identifiers to the classes that implement the 
attributes; and 

Figure 8 is a flowchart outlining an exemplary 
operation of the getAttribute ( ) method for the PKCS9 
10 class in accordance with a preferred embodiment of the 
present invention . 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The present invention provides a software 
5 methodology for managing PKCS #9 attributes that may be 
associated with a variety of data objects. These data 
objects are formatted according to other standards in the 
PKCS set of standards. The data objects and their 
associated attributes may be embedded within messages 
10 that are sent within a distributed data processing system 
between parties that desire certain types of security 
features provided by the PKCS standards. 

With reference now to the figures, and in 
particular with reference to Figure 1, a pictorial 
15 representation of a distributed data processing system is 
depicted in which the present invention may be- 
implemented. 

Distributed data processing system 100 is a network 
of computers. Distributed data processing system 100 

20 contains network 102, which is the medium used to provide 
communications links between various devices and 
computers connected within distributed data processing 
system 100. Network 102 may include permanent 
connections, such as wire or fiber optic cables, or 

25 temporary connections made through telephone connections. 

In the depicted example, servers 104, 114, 116 and 
118 are connected to network 102. Storage units 106 and 
122 are also connected to network 102, providing backup 
support for any or all of servers 104, 114, 116 and 118. 

30 In addition, clients 108, 110 and 112 are also connected 
to network 102, These three clients may be, for example, 
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personal computers or network computers. Distributed 
data processing system 100 may include additional 
servers, clients, and other devices not shown. 

In the depicted example, servers 104, 114, 116 and 
5 118 provide storage for data from clients 108, 110 and 
112. These four servers also provide data, such as boot 
files, operating system images, and applications to 
clients 108, 110 and 112. Clients 108, 110 and 112 are 
clients to one or all of servers 104, 114, 116 and 118. 

10 In the depicted example, distributed data processing 
system 100 may be the Internet, with network 102 
representing a worldwide collection of networks that use 
the TCP/IP suite of protocols to communicate with one 
another. At the heart of the Internet is a backbone of 

15 high-speed data communication lines between major nodes 
or host computers consisting of thousands of commercial, 
government, education, and other computer systems that- 
route data and messages. Of course, distributed data 
processing system 100 also may be implemented as a number 

20 of different types of networks, such as, for example, an 
intranet or a local area network. 

Figure 1 is intended as an example and not as an 
architectural limitation for the processes of the present 
invention . 

25 The present invention may be embedded within a' 

software application that provides some type of secure 
messages or cryptographic features to a user for a 
variety of purposes. For example, an application that 
employs the software methodology of the present invention 

30 may execute on any of the clients or servers shown in 
Figure 1. The application may use the present invention 
to create a data object representing an instance of a 
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PKCS #9 attribute, which is then associated with another 
PKCS- related data object and embedded within a PKCS #7 
cryptographic message. The cryptographic message may 
then be sent between clients and/or servers in network 
5 102, 

With reference now to Figure 2, a block diagram of 
an exemplary data processing system which may be 
implemented as a server or client, such as server 104 or 
client 108 in Figure 1. Data processing system 200 may 

10 be a symmetric multiprocessor (SMP) system including a 
plurality of processors 202 and 204 connected to system 
bus 206. Alternatively, a single processor system may be 
employed. Also connected to system bus 206 is memory 
controller/cache 208, which provides an interface to 

15 local memory 209. I/O bus bridge 210 is connected to 
system bus 206 and provides an int;:erface to I/O bus 212, 
Memory controller/cache 208 and I/O bus bridge 210 may be 
integrated as depicted. 

Peripheral component interconnect (PCI) bus bridge 

20 214 connected to I/O bus 212 provides an interface to PCI 
local bus 216. A number of modems 218-220 may be 
connected to PCI bus 216. Typical PCI bus 
implementations will support four PCI expansion slots or 
add-in connectors. Communications links to network 

25 computers 108-112 in Figure 1 may be provided through 
modem 218 and network adapter 220 connected to PCI local 
bus 216 through add-in boards. 

Additional PCI bus bridges 222 and 224 provide 
interfaces for additional PCI buses 226 and 228, from 

30 which additional modems or network adapters may be 

supported. In this manner, server 200 allows connections 
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to multiple network computers. A memory-mapped graphics 
adapter 230 and hard disk 232 may also be connected to 
I/O bus 212 as depicted, either directly or indirectly. 
Those of ordinary skill in the art will appreciate 
5 that the hardware depicted in Figure 2 may vary. For 
example, other peripheral devices, such as optical disk 
drives and the like, also may be used in addition to or 
in place of the hardware depicted. The depicted example 
is not meant to imply architectural limitations with 
10 respect to the present invention. 

The data processing system depicted in Figure 2 may 
be, for example, an IBM RISC/System 6000, a product of 
International Business Machines Corporation in Armonk, 
New York, running the Advanced Interactive Executive 
15 (AIX) operating system. 

Before describing the software methodology of the 
present invention for processing PKCS #9 attributes, 
Figures 3-5 provide some background information about the 
syntax and encoding of attributes that are used in the 
20 PKCS set of standards. 

With reference now to Figure 3, a diagram shows the 
Abstract Syntax Notation (ASN.l) for the X.500 Attribute 
type. An attribute is defined in the X.500 standard to 
be essentially a coupling of a unique object identifier 



25 S^S'^with some value. An attribute value can be composed 
of one or more items, and the data .type of the items 
themselves depends upon the type of the attribute. 

As stated, PKCS #9 defines a specific set of 
attributes. Currently, in the version 1,1 standard, 
3 0 there are nine such attributes, described in more detail 
below in Figure 6. The definition of each includes its 
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object identifier, the data type of its value, and 
whether its value is single-valued or multi-valued. 

With reference now to Figure 4, a diagram shows two 
examples of PKCS #9 attributes, each with sample values. 
5 EmailAddress attribute 400 is an example of a 

multi-valued attribute. The object identifier 402 has 
two value items, 404 and 406. These values have ASN.l 
data type IA5String, where IA5String is a sequence of 
ASCII characters. ContentType attribute is a 

10 single-valued attribute 408. The object identifier 410 
has a single value 412 that is also an object identifier. 

ASN.l notation defines the data types, and any 
software application can implement data type definitions 
in any suitable way: a C struct, a Java object, and a 

15 Pascal record are possible implementations: These 

disparate objects must be encodable in some standard way 
to ensure interoperability among the software 
implementing the defined objects. One way to accomplish 
this uniform encoding is through the Distinguished 



20 Encodi n g Rules (PER), , a method to transfor m an 

AS N. 1-def ineja_ obj^ct „in a byte arrav^in_sJLandard 
format. In this way, a software entity on one system may 
implement an ASN.l object in one fashion, encode it via 
DER, and transmit it to another software entity, which 

25 can then parse the DER byte array into its own 

representation of the same ASN.l object originally 
encoded. 

With reference now to Figure 5, a figure shows 
DER-encoding in hexadecimal format for the two PKCS #9 
30 objects depicted in Figure 4. In particular, encoding 
502 is for EmailAddress and encoding 504 is for 
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ContentType. The important feature of these encodings is 
that they are "distinguished" or unique. 

As mentioned previously, an application may use the 
present invention to create a data object representing an 
5 instance of a PRCS #9 attribute, which may then be 
associated with another PKCS-related data object and 
embedded within a message sent across a network. There 
are basically four operations that must be implemented 
within a robust application to fully support PKCS #9 
10 attributes: 

(1) An application should be able to build an 
attribute from its constituent parts, its object 
identifier, and its value. 

(2) An application should be able to convert an 
15 attribute object into a DER-encoded byte stream for 

transmission to other systems. 

(3) An application should be able to convert a 
DER-encoded byte stream into an attribute object. 

(4) An application should be able to distinguish one 
2 0 attribute from another and extract an attribute's value 

information. 

The PKCS #9 architecture outlined in this invention 
supports these PKCS attribute operations, such as 
construction, attribute conversion to and from 

25 DER-encoding, attribute differentiation, and attribute 
value extraction. By implementing the software 
methodology of the present invention in an 
object-oriented programming language, such as Java, some 
of these operations may be facilitated by having very 

30 specific attribute classes while other operations are 

facilitated by more general classes. The class hierarchy 
described below combines elements of specific and general 
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classes to implement PKCS-attribute-related operations in 
a manner which is extensible to user-defined attributes. 
"User-defined attributes" may include attributes that 
have specific user purposes in specific applications, 
5 i.e. attributes which are not contemplated as eventually 
becoming standard-defined attributes or are not 
promulgated as standard-defined attributes. 

In addition, a "user-defined attribute" may also 
include attributes that were not part of the PRCS #9 

10 standard when a software application implementing the 

present invention was deployed. At some later time, when 
an attribute that was previously recognized as a 
user-defined attribute then becomes part of the PKCS #9 
standard, the application may be updated so that the 

15 application recognizes the PKCS #9 standard-defined 
attribute and so that the attribute is no longer 
recognized as a user-defined attribute. In this manner, 
the present invention allows an application to be 
extended to user-created attributes and subsequent, 

20 standard-defined attributes. 

With reference now to Figure 6, a class hierarchy 
diagram shows an exemplary set of classes for use in the 
software methodology of the present invention for 
implementing PKCS-attribute-related operations in an 

25 extensible manner. PKCSDerObject 600 is an abstract 

class representing any object that can into encoded into 
or decoded from a DER byte stream. All subclasses of 
PKCSDerObject must implement encode and decode methods. 
Def inedAttribute 602 is an abstract class 

30 representing any attribute that is "known" to the system; 
that is, those attributes that have individual class 
implementations and that are registered with the PKCS9 
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class. The registration process is discussed below with 
respect to the PKCS9 gateway class 610. The subclasses 
of Def inedAttribute 602 must implement a number of 
methods to return attribute-specific information such as 
5 the attribute's common name and whether the attribute is 
single-valued or multi-valued. 

PKCS #9 standard-def ined-attribute Classes 604 are a 
set of classes representing the attributes defined. in 
PKCS #9. As of version 1.1 of the PKCS #9 standard, 

10 there are nine defined attributes: ChallengePassword, 
EmailAddress , SigningTime , ContentType , 
ExtendedCertif icateAttributes, UnstructuredName , 
Countersignature, MessageDigest , and UnstructuredAddress , 
Additional classes can be added to this set as further 

15 versions of the PKCS #9 standard are developed and 

approved. All of these classes implement the abstract 
methods in their parent class, Def inedAttribute 602. 
User-def ined-attribute Classes 606 are a set of 
' classes representing ASN.l Attribute types that are not 

20 defined in the PKCS #9 standard (and therefore not 
represented by a class in PKCS #9 

standard-def ined-attribute classes 604) but that are 

known to the system and registered with the PKCS9 gateway 

class 610. Like the standard PKCS #9 
25 standard-def ined-attribute classes 604, 

user-def ined-attribute classes must implement the 

abstract methods in Def inedAttribute . 

Undef inedAttribute 608 represents any attribute that 

is unknown to the system. That is, there is not a 
30 specific class that implements the attribute, so the 

PKCS9 class 610 cannot map the attribute object 

identifier to an implementing class. The 
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Undef inedAttribute class 608 allows the decoding of 
arbitrary attributes that may be undefined on the system. 
The Undef inedAttribute class 608 includes an 
Objectldentif ier data member which is the attribute OID 
5 and a byte array data member which is the DER-encoding of 
the attribute value. 

PKCS9 gateway class 610 serves as the gateway to all 
the attributes on the system, both known and unknown. It 
has a variety of getAttribute ( ) methods that allow easy 

10 instantiation of an attribute by OID and value, string 
name and value, or DER-encoding. PKCS9 gateway class 610 
will interpret the input and return an instance of the 
proper Def inedAttribute or an Undef inedAttribute . 

All attributes defined in the PRCS #9 standard (and 

15 therefore represented by a class in PKCS #9 

standard-def ined-attribute classes 604) are statically 
registered within the PKCS9 gateway class 610. That is, 
the PKCS9 gateway class 610 has a mapping of each 
attribute's unique OID to the class that implements it. 

20 To register user-defined attributes, the user must first 
implement the attribute as a subclass of Def inedAttribute 
since the PKCS9 gateway class 610 uses the abstract 
methods defined in Def inedAttribute and then enters the 
attribute- OID and its implementing class in a 

25 configuration file. 

Figure 6 shows two user defined attributes: 
"NetscapeComment " , an attribute used in many applications 
yet not one of the attributes defined in the PKCS 
standard, and "SomeAttribute" , an exemplary name chosen 

30 to suggest a user-defined attribute for a particular 
application. When the PKCS9 gateway class 610 is first 
loaded, it will read a configuration file and internally 
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store the mapping information for OIDs of user-defined 
attributes. Thereafter, when a getAttribute ( ) method is 
called and the PKCS9 gateway class 610 detects a 
user-defined OID in the input arguments, it will be able 
5 to access the proper class for attribute instantiation. 
This registration process and the basic means of 
obtaining an attribute via the PKCS9 gateway class 610 is 
discussed in more detail below with respect to Figure 7. 
The logic followed by the getAttribute ( ) method is 
10 discussed in more detail further below with respect to 
Figure 8 . 

Note that a configuration file may be in a default 
location or may be in a location defined by a Java 
property defined in the java . security configuration file. 
15 If a configuration file is property-defined, the PKCS9 
gateway class 610 must have permission to read the 
property. In either case, the PKCS9 gateway class 610 
must have permission to read the configuration file 
itself. 

20 Before discussing flowcharts for the algorithms 

associated with the present invention, it is useful to 
discuss the PKCS-attribute-related operations of 
construction, attribute conversion to and from 
DER-encoding, attribute differentiation, and attribute 

25 value extraction in more detail. 

Constructing an attribute using the classes defined 
in the present invention can be accomplished in different 
ways, depending upon what information the user has at the 
time. If the type of the required attribute is known, 

30 then that attribute may be instantiated directly using a 
constructor that takes a meaningful data type. For 
example, if an UnstructuredName attribute is needed, that 
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attribute may be instantiated by calling the 
UnstructuredName constructor that takes a String argument 
(the name) . There is no need to convert the name value 
to the DER-encoding of its ASN.l data type. As another 
5 example, the ChallengePassword attribute may be 

instantiated by calling the ChallengePassword constructor 
that takes a char[] argument (the password). Note that 
security-sensitive data, such as passwords, should not be 
represented as String data types which are immutable. 

10 If the user has an object identifier (OID) and some 

value, but does not know to which attribute class the OID 
corresponds, the PKCS9 . getAttribute (Objectldentif ier , 
Object) method associated with the PKCS9 class, such as 
the PKCS9 gateway class 610 shown in Figure 6, may be 

15 used to construct the attribute. The PKCS9 class will 
return an instance of the correctly defined attribute if 
the attribute OID is known to the system or an instance 
of UndefinedAt tribute if the OID is unknown to the 
system. 

2 0 If the user has only a DER-encoded byte stream, the 

PKCS9 . getAttribute (byte [] ) method may be used. This 
method will extract the attribute OID from the byte 
stream and then instantiate and return the proper 
attribute object. 

2 5 Another operation is the conversion of an attribute 

object to a DER-encoded byte stream. Because all 
attributes are subclassed from PKCSDerObject , each must 
implement an encode ( ) method. Converting an attribute 
object to its DER-encoding requires a simple call to the 

3 0 encode ( ) method . 

The reverse conversion of a DER-encoded byte stream 
to an attribute object is also possible. Because all 
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attribute classes are subclassed from PKCSDerObject , each 
attribute class must implement a decode ( ) method. 
Explicitly creating an attribute object from a DER byte 
array requires using the attribute's default constructor 
5 and then calling that object's decode ( ) method. 

Alternatively, the PKCS9 gateway class, such as PKCS9 
gateway class 610 in shown in Figure 6, can be used to 
convert any DER-encoded attribute to an attribute object, 
and this relieves the user from having to know how to 

10 instantiate an attribute object explicitly by knowing the 
attributes type and calling the appropriate constructor. 

Other useful operations are attribute 
differentiation and value extraction. An important 
usability feature of attributes is the ability to easily 

15 distinguish them from one another. Having a separate 

class implement each attribute allows the user to search 
for a particular attribute type using the "instanceof" 
operator. For example, X.509 extended certificates can 
include attributes. To find the signing time of an 

2 0 extended certificate, one could cycle through the 
attribute objects in the certificate object using the 
"instanceof SigningTime" comparator. There is no need to 
examine OIDs values within the attribute objects to find 
the correct one. 

25 It is also preferable to be able to extract the 

attribute value in a form that is immediately meaningful, 
rather than in a form that must be converted before use. 
For example, the value of an EmailAddress attribute can 
be extracted directly into an array of Strings. This 

30 relieves the user from having to convert an internal 
representation of the value whether it be a DER byte 
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stream or a series of Objects, for example -- into 
Strings after value extraction. 

With reference now to Figure 7A, a flowchart shows 
the request of an attribute object via the PKCS9 gateway 
5 class. The PKCS9 gateway class is loaded (step 702), 
Upon loading, the static initializer block in this class 
is run. Static initialization includes reading in the 
data from the user-def ined-attribute configuration file. 
The user-def ined-attribute configuration file is 

10 read (step 704) . The file is stored on disk either in a 
default location or in a location specified by a Java 
security property. If the latter, the PKCS9 gateway 
class must first read the Java property to find the file 
location, then access the file itself. 

15 In the course of execution, a Java program may 

request an attribute instance by calling a 
PKCS9 .getAttribute ( ) method, passing in the appropriate 
arguments (step 706) . The logic followed by the 
PKCS9 .getAttribute ( ) method (step 708) is described more 

20 fully in Figure 8. If there are more attributes to 

process (step 710) , then control is transferred to step 
706. Otherwise, the request of the Attribute object is 
completed. 

With reference now to Figure 7B, a diagram shows an 
25 example format of a user-defined attribute configuration 
file that maps attribute object identifiers to the 
classes that implement the attributes. The PKCS9 gateway 
class reads mappings, e.g., at initialization time, in 
configuration file 712 and stores them internally in an 
30 appropriate data structure. In this example, object 

identifier 714 maps to class 716 and object identifier 
718 maps to class 720. 
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With reference now to Figure 7C, a table shows an 
example of mappings from object identifiers to the 
classes that implement the attributes. The first nine 
entries are PKCS #9 standard-def ined-attribute classes 
5 where both the object identifier and class names are 
predefined. Since these values are fixed, they do not 
need to be stored in the configuration file. Rather, the 
information in the configuration file is added to the 
attribute mappings after the predefined values. As one 

10 of ordinary skill in the art will appreciate, the 
attribute mappings shown in Figure 7C could be 
implemented as a hash table, an association list, or 
similar data structure. This set of mappings will 
contain the object identifier and the class name for all 

15 registered attributes, including the PKCS #9 

standard-def ined-attribute classes and extended or 
user-defined attributes. 

When a "get "-type method in the PKCS9 gateway class 
is invoked, the object identifier is extracted from the 

20 argument, the class name associated with the object 

identifier is determined from the set of mappings, and a 
constructor in the associated (i.e. mapped) class is 
called. The PKCS9 "get" method then returns an instance 
of a specific defined attribute, or an instance of an 

25 Undef inedAttribute if the object identifier does not have 
a class mapping. 

With reference now to Figure 8, a flowchart shows 
the logic of the getAttribute ( ) method for the PKCS9 
gateway class. This figure is an expansion of step 708 

30 in Figure 7A. Once a PKCS9 . getAttribute ( ) method is 

called, the attribute object identifier is extracted from 
the input arguments (step 800) . Depending on the 
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signature of the getAttribute ( ) method, the OID may be in 
String form, in Objectldentif ier form, or in a 
DER-encoded byte array. In each case, the PKCS9 gateway 
class is able to convert the OID to the form in which the 
5 object identifiers in the OID-class mappings for the 
PKCS9 gateway class are stored. 

The PKCS9 class determines if the requested OID is 
one that has been registered, either statically (as an 
attribute class corresponding to the standard-defined 

10 PRCS #9 attributes) or at runtime through the 

user-defined attribute configuration file (step 802) . 

If the PKCS gateway class has found a registered 
OID, then a constructor of the class mapped to that OID 
is called with the value argument passed to the 

15 PKCS9 .getAttribute 0 method (step 804). The specific 
attribute constructor will return an attribute instance 
to the PKCS9.getAttribute() method. 

If the PKCS9 gateway class has not found a 
registered OID, then the constructor of the 

20 Undef inedAttribute class is called (step 806) . This 

constructor will return an Undef inedAttribute instance to 
the PKCS9 . getAttribute ( ) method . The 

PKCS9 . getAttribute ( ) method returns the attribute back to 
its caller (step 808) . 

25 The programming language for the preferred 

embodiment of this invention is Java, but as one of 
ordinary skill in the art will appreciate, implementation 
could be in a wide variety of programming languages, such 
as C, Pascal, C++, and so forth. Implementation in an 

30 object-oriented language, such as C++, would be easier 
than in a language like C that is not object-oriented. 
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In smnmary, the architecture outlined in the present 
invention provides several usability features for PKCS 
attributes, including those that are not defined in the 
PKCS #9 standard: 
5 (1) Distinct classes for each defined attribute 

allows for easy instantiation either directly or through 
the PKCS9 gateway class. 

(2) Distinct classes for each defined attribute 
allows for easy differentiation between attributes. A 

10 specific attribute type can be found by using the 

"instanceof" operator with no need to examine internal 
data members . 

(3) Distinct classes for each defined attribute 
allows attribute values to be extracted in forms 

15 meaningful to the user. For example, the value of a 

SigningTime attribute is known to be a Date object, and 
is directly retrievable and usable as such. There is no 
need to extract values generically as Objects or as byte 
arrays (DER-encodings) which then must be converted to 

20 usable objects. 

(4) All attributes implement encode and decode 
methods for easy conversion to and from DER byte streams. 

(5) Both defined and undefined attributes are 
supported. 

2 5 (6) The architecture is extendible so that new 

attributes can be implemented and registered with the 
system. 

It is important to note that, while the present 
invention has been described in the context of a fully 
30 functioning data processing system, those of ordinary 
skill in the art will appreciate that the processes of 
the present invention are capable of being distributed in 
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the form of a computer readable medium of instructions 
and a variety of forms, and that the present invention 
applies equally regardless of the particular type of 
signal bearing media actually used to carry out the 
5 distribution. Examples of computer readable media 

include recordable- type media such a floppy disc, a hard 
disk drive, a RAM, and CD-ROMs and transmission- type 
media such as digital and analog communications links. 
The description of the present invention has been 

10 presented for purposes of illustration and description 
but is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 
the art. For example, this general architecture can be 

15 utilized in a variety of operating systems. It can also 
be implemented in different programming languages. It 
can also be extended to include new PRCS attributes as 
the Public Key Cryptography Standards evolve over time. 
The embodiment was chosen and described in order to best 

20 explain the principles of the invention and the practical 
application, and to enable others of ordinary skill in 
the art to understand the invention for various 
embodiments with various modifications as are suited to 
the particular use contemplated. 



